home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 205 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.6 KB
  1. From: richard@atheist.tamu.edu (Richard Henderson)
  2. Message-ID: <4ep4ii$l81@news.tamu.edu>
  3. X-Original-Date: 1 Feb 1996 01:21:22 GMT
  4. Path: in2.uu.net!bounce-back
  5. Date: 01 Feb 96 02:01:25 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: Cleaning auto_ptr copy semantics.
  9. Organization: Texas A&M University, College Station, TX
  10. References: <gregorDLrrun.K2x@netcom.com>
  11. Reply-To: rth@tamu.edu
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBFAgUBMRAfDuEDnX0m9pzZAQGPAgF/fOl65cXYULMKbnk4oOEsUURqaRkOuRrK
  14.     e/6hTBpCfOUcX4DDQAah7DkBYoFfdGep
  15.     =YWze
  16.  
  17. In article <gregorDLrrun.K2x@netcom.com>,
  18. Greg Colvin <gregor@netcom.com> wrote:
  19. >The smallest change I can see that preserves the semantics of strict 
  20. >ownership is to separate the concepts of "holding a pointer" and "owning 
  21. >an object", so that more than one auto_ptr can hold a pointer to an object,
  22. >but only one auto_ptr can own the object.  
  23.  
  24. The problem I see with this is that a holder cannot see when
  25. an object goes away.  With the old transfer of control semantics,
  26. there is never a dangling pointer to an object.  Dangling pointers
  27. are, in my opinion, much more dangerous than NULL pointers.
  28.  
  29. Also, I see no difference, wrt temporaries, between your solution
  30. and making "px" mutable.  Both solutions actually change the temporary.
  31.  
  32. >Note also that reset() must go, since the idiom p.reset(q.release()) 
  33. >cannot safely transfer ownership.  I would happily remove get() as well, 
  34. >since its primary use may turn out to be leaking pointers.
  35.  
  36. Without get(), how do you (without moving to full reference counting,
  37. which I think should exist _along side of_ auto_ptr) pass 
  38.  
  39.     auto_ptr<foo> a;
  40.  
  41. to a function bar(), and retain control of the object after bar()
  42. terminates?  The current
  43.  
  44.     extern void bar(foo *);
  45.     bar(a.get());
  46.  
  47. is quite satisfactory.  On the other hand
  48.  
  49.     extern void bar(foo *);
  50.     foo *tmp = a.release();
  51.     bar(tmp);
  52.     a.reset(tmp);
  53.  
  54. violates one of the main reasons for having auto_ptr (cleaning up
  55. on the way out of an exception within bar()), and
  56.  
  57.     extern void bar(const auto_ptr<foo> &);
  58.     bar(a);
  59.  
  60. destroys a's object when bar returns (if nothing happens within
  61. bar() to cause it to be destroyed sooner) under both the original
  62. semantics and your revised semantics.
  63.  
  64. >    template<class Y> auto_ptr(const auto_ptr<Y>&);                     |
  65. >    template<class Y> auto_ptr& operator=(const auto_ptr<Y>&);          |
  66.  
  67. I do like the template members though.
  68.  
  69.  
  70. r~
  71. ---
  72. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  73.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  74.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  75.